Publishing framework

Brett McLaughlin gives the following definition in Java and XML:
"Just as a web server is responsible for responding to a URL request for a file, a web publishing framework is responsible for responding to a similar request; however, instead of responding with a file, it often will respond with a published version of a file. In this case, a published file refers to a file that may have been transformed with XSLT, or massaged at an application level, or converted into another format such as a PDF. The requestor does not see the raw data that may underlie the published result, but also does not have to explicitly request that publication occur."

A web publishing framework provides a clean separation between content and presentation.
Cocoon is a Java publishing server that relies on XML, DOM and XSL to provide web content.

Though PageBox can integrate any publishing framework as far as it runs on a Java Application Server, we chose Cocoon to illustrate the integration mechanism and benefits because:
• It is excellent and mature
• It is free and Open Source
• Many programmers use it

Cocoon

This nice picture shows the Cocoon design:



When Cocoon receives an HTTP request, it invokes a Producer. The Producer generates an XML document.
Then the reactor invokes processors to transform or massage the document.
Eventually it invokes a formatter to format the document and returns the formatted document to the requestor.

How the reactor knows which processors and formatter it must invoke?
Through XML processing instructions included by the producer or by processors.

Cocoon design is quite simple and flexible. You also can extend it by writing your own producers and processors.

Data provider repositories

Data provider repositories describe Web services that can be accessed using XML over HTTP, XML over SMTP, SOAP and IIOP. Some Data provider repositories exist today:
• RosettaNet
• ebXML

Web service descriptions can be stored in and retrieved from a Universal Description, Discovery and Integration (UDDI) repository.

UDDI is defined to allow different technologies working together. It supports describing any socket, IIOP, XML over HTTP binding. However today only SOAP and HTTP binding are standardized with Web Service Description Language (WSDL). You can download its specification on IBM or Microsoft sites

We regard UDDI as the best standard for Data provider repositories.

The selection and the use of Data provider repositories is a Presentation provider task. The task of PageBox framework is only to host the stubs generated from these repositories.

Cocoon support in PageBox

Cocoon alone



From an Application Server point of view it is just like JSPservlet (current PageBox implementation) or SOAP server. It is a special servlet you configure in your application server to handle some URLs.

Here Cocoon generates different presentations from a single XML content.

PageBox as a distributed Publishing framework



With the JSPservlet version 1.0.4 Cocoon support, Cocoon is called by PageBox when PageBox has to process an Cocoon suffix (typically .xml) for a given Web archive.

An archive can contain a combination of:
• Java classes
• Resources such as images and static (HTML) pages
• XML and XSL resources

XML and XSL resources are managed like regular resources, which means that PageBox finds them:

1. In the archive
2. Otherwise in the directory the archive was downloaded from

Cocoon and other archives we can need (such as SOAP) are loaded by PageBox (support archives on the diagram). It means that all PageBoxes in a Constellation can provide the same set of archive versions.

PageBox + Cocoon + Data provider invocation



Here we implement processors that invoke Web services using XML over HTTP or SOAP.

A processor is a Java class that receives an XML request and returns an XML response.

• The XSL processor is simply a special sort of processor that produces the response through an XSL transformation of the request.
• A Network processor is another sort of processor that produces the response through a Web service invocation.

A network processor is a generic piece of code that integrate smoothly with producers, other processors and formatters in the Cocoon frameworks. It means that you still can write a dynamic presentation using only XML and XSL.

The diagram below shows a simple example of networked pipeline:



• The browser requires a Cocoon managed resource - typically an XML file.
• Cocoon invokes a producer - typically an XSP producer - to generate an XML message. Note that PageBoxes supports XSP compilation on the fly.
• Cocoon invokes the XSL processor that transform the message in a format suitable for the subsequent Network query.
  When you need to invoke different Data Sources depending on the request, this step allows converting from your query format to the Data source query format.
• Cocoon invokes a Network processor - XML over HTTP or SOAP - and adds the response to the message.
  In case of failure, the Network processor returns a response with an error element and diagnosis information.
  The Network processor cancels the request if it takes more than TimeToComplete to complete.
• Cocoon invokes the XSL processor to transform the aggregate message - response in a format suitable for formatting.
• Cocoon invokes a formatter to return the browser response.

This model is quite flexible. You can invoke different Data providers and merge their responses.

Roles in a PageBox/Cocoon infrastructure

1. Data provider

   

   The Data provider publishes its Web services on a repository such as:

   • RosettaNet
   • ebXML
   • A UDDI directory

2. Presentation provider

   At design time, the Presentation provider scan repositories for suitable Web services. It can get a WSDL specification of the service and generate the invocation code using tools such as IBM toolkit.

   The Presentation provider can also get the messages or SOAP definition from the provider. Existing Network providers require the use of XML over HTTP or SOAP but it is also possible to write a Network provider for EDIFACT, EJB, CORBA or custom protocol over TCP or UDP.

   Most of the Presentation Provider tasks are the same as with Cocoon alone:

   • Design content
   • Design logic.
   • Design rendering.

   Packaging simply means building a Presentation Java archive (jar) with xml and xsl files and possibly Java classes.

   

   Once the Presentation Provider has generated the Presentation Java archive, it publishes on a PageBox repository. Then PageBox repository deploys the archive on subscribing PageBoxes.

3. PageBox host

   The PageBox host can subscribe to the repository either before or after the publication.

   • In the first case, it gets the Presentation when it is published.
   • In the latter case, it gets the Presentation when it subscribes.

   

   Once the Presentation is deployed, the Presentation provider and the Web service repositories are no longer involved. PageBoxes invoke Web services.

Technical data

1. Components to download
2. Installation guide